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0 A method of verifying receipt and acceptance of electronically delivered data objects. 



0 The method of the invention consists, for the 
sender of a data object, first modifying the object 
into an unusable form and inserting into it a verifica- 
tion indicia and an enabling facility which is capable 
of rendering the data object into an operative state 
when certain prerequisite conditions are met. The 
receiver or user inserts the data object into a worl<- 
station to view portions of the enabling facility, and 
then enters his acceptance or rejection of tenns and 
conditions relating to the use and installation of the 
data object in response to prompts friat are pre- 
^sented by the enabling facility. If the prerequisite 
^conditions are met and agreed to, the data object is 
©rendered into a usable and operable data form. 
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PRESENT THE APPLICABLE TERMS AND CONDJTIONS 
TO THE USER BY OISPLAYIMC THE rOLLOWtNC: 



RECEIPT AND ACCEPTANCE MENU SCREENS (MAY 
tNauOE MENU. WARRANTY ANO LICENSE 
AGREEMENT SCREENS) 



If THE USER DOES NOT ACCEPT THE TERMS ANO 
CONOniONS DISPLAYED BY RECEIPT ANO 
ACCEPUNCe SCREENS. ABORT AND RETRUN TO 
THE ORISJNAU OBJECT MODULES/ FILES. 
DO NOT ACTIVATE INSTAtlATlON OF THE 
OBJECT. 
ELSE 

CONTINUE. 



1 SEARCH FOR THE CHARACTER STRING, AND 
MODIFY CANO ENCRYPT) THE STRING 
INSERTED BY THE OBJECT ORIGINATOR 
(NTOTHE OBJECT'S MAJOR FiLEtS) 



-2. ENABLE THE OBJECT BY UNSCRAMBLING ANO/OR 
DECRYPTING PSEUDO FILENAMES TO THE REAL 
FILENAMES USING THE TABLE PROVIDED BY 
THE OBJECT ORIGINATOR. 



3. RECALCULATE THE OBJECT'S CHECK- 
SUM USING THE CHECKSUM LOCATION 
PROVIDED BY THE ORIGINATOR. 
(OPTIONAL FEATURE). 



4. MODIFY THE RECEIPT AND ACCEPTANCE PROGRAM 
ITSELF BY DELETING THE CODE THAT PROVIDES 
FOR MODIFICATION OF THE OBJECT'S FILEC5). 



5. ACTIVATE THE OBJECT FOR USE OR DISPLAY BY 
TRANSFERRING CONTROL TO THE OBJECT 
MOOULC/FILE NAME PROVIDED BY THE OBJECT 
ORIGINATOR. . 



Xerox Copy Centre 



WIST00006290 



BP 0 367 700 A2 



A METHOD OF VERIFYING RECEIPT AND ACCEPTANCE OF ELECTRONICALLY DELIVERED DATA OB- 
JECTS ! 



This invention relates to receipt and accep- 
tance verification techniques for documents, li- 
cense agreements, contracts, or computer pro- 
grams generally, and more specifically, it relates to 
a method for verifying receipt and acceptance of 
electronically transmitted and/or magnetically re- 
corded data objects. 

While a variety of prior art techniques exist for 
protecting electronically transmitted and/or 
magnetically-recorded- data objects, all of these 
that are presently known require either encryption 
and the use of a decrypting key or algorithm which 
is normally only available to a previously autho- 
rized recipient or they require prior approval for 
sending to the recipient Other than by these tech- 
niques, no present system or technique is known 
which is self-verifying as to the fact that the recipi- 
ent has actually received the data object, agreed to 
the authorization conditions of its receipt or use 
and installed it for reading or use. 

In the field of computer program products, i.e. 
"software**, unauthorized duplication and/or access 
and usage Is a common problem. U.S. Patent 
4.757.534 shows one example of a cryptographic 
technique for protecting such programs. The user 
must have a password which will allow the encryp- 
ted program to be recovered at a prescribed and 
designated site that has a properly implemented 
and initialized decryption feature. 

Similarly, U.S. Patent 4,757.533 deals with a 
security system for a personal computer which 
utilizes automatic encryption and decryption for 
files In the personal computer. 

These prior art systems, and others of similar 
type, require the prearranged installation of encryp- 
tion or decryption features and/or "keys" such as 
passwords before a user or recipient can utilize an 
eiectronically-delivered or magnetically-recorded 
and delivered data object that has been protected 
by encrypt on or other disabling techniques. This is 
a significant drawback in the field of computer 
programing sales and use. particularly in^ systems 
which would download application programs for 
use at a local workstation or persona! 
computer/system. In the latter instance, the pro- 
gram or data object would be electronically trans- 
mitted and received, but elaborate systems are 
used to preauthorize the recipient by giving pass- 
words or the like which must be carefully recorded 
and kept track of for accounting purposes and for 
billing. 

In light of the foregoing known shortcomings 
with the prior art systems and techniques for elec- 
tronic distribution of data objects, the object of the 



present invention is to provide an improved method 
of securing electronic data objects and for verifying 
that they have been received and accepted which 
does not require prior authorization for receipt or 
5 the installation of previously authorized and re- 
leased keys, passwords or the like. 

The foregoing and still other object that are not 
specifically enumerated, are met in the present 
invention by a new system. In this system, the 

10 sender or originator of an electronic data object 
can later verify that the data object was actually 
received and accepted, in this system the data 
object itself controls the verification for the receipt 
and acceptance thereof. The sender or originator of 

/5 the data object first modifies the object to be 
delivered, rendering it unusable or inoperative in 
the form in which it will be initially received by the 
user. The originator or sender inserts into the data 
object a verification indicia and an enabling facility 

20 which is capable of rendering the inoperative data 
object into an operative state when certain pre- 
requisite conditions, contained in the verification 
and enabling facility, are met The sender or origi- 
nator then merely transmits (or records and deliv- 

25 ers) the modified and unsable data object tiiat 
contains the verification indicia and enabling facility 
to a recipient The recipient or user receives ttie 
modified and unusable data object and inserts or 
loads it into his/her workstation or computer having 

30 a CRT screen display, printer or the like. This 
allows the user to view portions of the enabling 
fadlity contained in the data object Screen dis- 
plays or messages prompting the user to enter 
responses are presented during tills phase of in- 

35 stallation of tine data object The user enters his or 
her acceptance or rejection of terms and conditions 
relating to the use and installation of the data 
object in response to prompts ttiat are presented 
by tiie enabling facility on tiie screen, printer or 

40 other interface that is humanly readable. That por- 
tion of tiie data object that contains the enabling 
facility then examines tiie user's responses and, if 
tiie prerequisite conditions are met and agreed to, 
renders the data object into a usable and operable 

45 form (including a modification of the verification 
Indicia) and records tiie result and may also cap* 
ture the user's identitication information. Alter- 
natively, if tiie prerequisite conditions are not met 
or agreed to. it terminates without rendering the 

50 data object into a usable and operable form. This 
ends the process. 

The invention will now be described witii re- 
spect to a preferred embodiment in reference to 
the accompanying drawings wherein: 
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Rgure 1 is a brief flow chart of steps taken 
by the data object originator or sender prior to 
sending or delivenng the data object to a user. 

Rgure 2 is a brief flow chart illustrating the 
operation of the invention at the recipient or user's 
workstation or computer. 

Rgure 3 illustrates a detailed processing 
flow chart of the operation of the invention at the 
recipient or user's workstation or computer. 

The invention will be descrit>ed with reference 
to the figures in the exemplary context of a system 
for delivering computer programs (software pro- 
ducts) having license terms and conditions that 
must be agreed to prior to the user's being granted 
use of his or her copy of the software product. 
Numerous other examples are possible, any of 
which relate generally to the problem of verifying 
that a recipient has actually received a data object 
and has agreed to certain terms and conditions 
concerned therewith. Other examples may be doc- 
uments that normally require registered and signed 
receipt mail delivery, contracts or other documents 
having legal significance, itemized buying and sell- 
ing arrangements, bills of lading, or any environ- 
ment in which a traceable record (within the data 
object itself) of actual receipt and acceptance of 
the data object is required. 

In the preferred embodiment of the invention 
described, an example chosen from the field of 
data processing Is given. In this example, the "data 
object" may be a computer program (software 
product) intended for use on a workstation or per- 
sonal computer/system. In such an environment, 
the normal users wish to obtain their copy of the 
relevant software product, carry it home (or to their 
workstations) and use it. Normally, these software 
products are accompanied by a "shrink wrapped" 
license agreement which details the terms and 
conditions of use which the buyer, or more appro- 
priately, the "licensee" is deemed to be bound by 
virtue of his or her opening and use of the contents 
of the package. If high security over unauthorized 
duplication or usage of programs is desired in such 
an environment, detailed record keeping via se- 
rialization of the software product, signed receipts 
obtained at the time of purchase or license, de- 
tailed record keeping and auditing procedures and 
the like are often necessary. These are expensive 
and time consuming. 

It wouki be far more desirable in today's elec- 
tronic communication environment to provide soft- 
ware products at a central access point which 
could be accessed on request, and whose contents 
could be made available to or even downloaded for 
users on request Since the users may come and 
go and since access to the central facility may b© 
difficult or cumbersome to regulate, it would be 
more desirable still if any potential user could 



merely "dial up" the central facility and request 
access to and delivery of any given software prod- 
uct This would mean that prior authorization proce- 
dures, i.e. delivery of decryption or security keys or 

5 codes or routines would not be ordinarily possible 
or even desirable. Additionally in order to over- 
come the relatively high cost of creating diskettes 
or cassettes of recorded software products for de- 
livery, the electronic distribution and duplication 

w method holds high market appeal but offers as well 
the opportunity for more prevalent abuse through 
unauthorized access, copying, and/or use. 

Into this environment, the present invention fits 
nicely as a solution to the problem; this invention 

rs may be implemented within the electronic data 
object itself and which is self-executing upon its 
receipt and acceptance by a user or requester. 

The prefenred embodiment will thus be de- 
scribed in the context of a system for delivery via 

20 electronic means of computer programs (software 
products) which provide auto matic verification that 
the requester or recipient has actually received the 
software product and has agreed to the terms and 
conditions regarding its use. 

25 The present invention provides a technique for 
the protection of electronically-distributed software 
products which are to be licensed to requesting 
end users who have not previously been authorized 
or provided with any specialized access keys or 

30 decryption programs or devices. The technique 
itself is based upon the premise that both the 
usability and installability of electronically-delivered 
software products may be conditioned upon the 
end user's receipt and acceptance of the terms 

QS and conditions regarding the specific software 
product A license agreement of the readable form 
normally enclosed with recorded diskettes or cas- 
settes is incorporated into the electronically-deliv- 
ered data object or software product and is deliv- 

40 ered therewith. The Invention presents to the user 
the terms and conditions regarding the use, 
charges for and other relevant data pertaining to 
the software product for the user's review and 
acceptance or rejection. The Invention presents 

46 prompts or questions to the user and records the 
responses as evidence that a user did receive, and 
has or has not agreed, to the terms and conditions 
regarding the software product If the user does 
agree to the terms and conditions and so indicates, 

60 the invention provides for "enabling" the delivered 
disabled and unusable software product It also 
provides for mari<ing that user's copy with indicia 
which Indicates acceptance and may also deter- 
mine the identity of the user. The invention thus 

65 provides the electronic equivalent of "breaking of 
the shrink wrap seal" involved in the nomial hard 
copy of software license agreements delivered with 
physical diskettes or cassettes. It replaces prior 
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authorizations via signed agreements which are 
prearranged in electronic distribution systems 
which require that potential users first sign up and 
agree to the license agreement terms and con- 
ditions in order to receive a decryption key or 
password which will grant them access to the de- 
sired software products. 

The invention requires some preparation on the 
part of the software product originator or sender. 
As shown in Rgure 1. the software product origina- 
tor is required to include with the software product, 
or electronically-deliverable data object, modules of 
code that provide a presentation and acceptance 
verification and enabling facility (enabling pro- 
gram). The software product originator is further 
required to provide certain input to the enabling 
program. The originator must provide the language 
of the pertinent terms and conditions of the license 
agreement by recording them as screen or output 
display code that will be accessed automatically by 
the enabling program. An appropriate prompt as to 
acceptance or rejection of the terms and conditions 
of the license agreement may also be provided in 
this data by the originator. In addition, the origina- 
tor must insert an arbitrary predefined character 
string of the originator*s own choosing into the 
software product's major module(s) or file(s). This 
arbitrary character string which may be called a 
"verification indicia" may be recognized by the 
software product itself as will be described later. It 
also will be modified and/or encrypted after the 
license agreement has been read and accepted by 
the user to indicate that the user has accepted the 
terms and conditions of the license agreement as 
will be later described. 

It is also incumbent upon the originator of the 
software product to create a copy of the software 
product with the pertinent file names or module 
names given "pseudo names" which are scram- 
bled and to provide a table with cross references 
showing the correspondence between the pseudo 
or scrambled file names and the actual file names 
of the software product. These actual file names 
will not be restored and the software product itself 
will not be a usable program. The enabling pro- 
gram will restore the actual file names and un- 
scramble the contents in response to acceptance 
by the user of the terms and conditions accom- 
panying the software product. 

The originator of the software product must as 
noted earlier, provide a copy of the unscrambling 
and enabling facility. This is a short program rou- 
tine as will be illustrated later. Finally, the originator 
should provide a batch file or installation routine to 
which control may be transfen'ed at the completion 
of the acceptance and verification process after the 
user has .indicated his or her acceptance of the 
terms and conditions regarding use of the software 



product. 

Before proceeding to a detailed description of 
the overall operation that occurs for enabling the 
software product for use at the user's computer or 
5 workstation, the basic concepts are summarized as 
follows: 

The programs, which are the preferred emtjodi- 
ment of this invention, are incorporated into and 
become an integral part of the software product to 
10 be actually delivered. This portion of the invention 
actually presents the applicable terms and con- 
ditions of a license agreement to the end user by 
displaying license agreement screens as the initial 
step during the installation process of the software 
;5 product on the user's system. If the end user does 
not indicate acceptance of the terms and con- 
ditions of the applicable license agreement, the 
enabling program portion of the invention will abort 
operation, make no modifications to render the 
20 associated software product usable and will return, 
control to the user's operating system. In effect 
"no harm" has been done and the end user can 
follow whatever procedures are desired for return- 
ing the effectively "unopened" software product or 
25 can destroy it as applicable. If, however, the user 
does indicate acceptance of the terms and con- 
ditions of the applicable license agreement, the 
portion of the preferred embodiment code will take 
additional actions. It will electronically record the 
30 user's acceptance by modifying certain predefined 
fields within the software product's applicable 
module(s) and file(s). It will also restore the original 
file names thereof, to allow them to be usable 
again, thus rendering the formeriy unusable pro- 
35 gram into a usable state. And it will modify itself, 
finally, by deleting the code portions which allowed 
unscrambling or decryption and reconstnjction of 
the delivered software product and will hand control 
over to the installation module or startup routine of 
40 the software product. 

The primary advantage of this new system of 
security and delivery is that it essentially makes 
electronically distributed programs "Self protect- 
ing". It facilitates easy customization of license 
45 provisions and/or warranty information and provides 
a wide range of asset protection mechanisms us- 
able at the discretion of tiie software product origi- 
nator. Those skilled in the art will realize that, within 
the scope of this invention. It is possible to redefine 
so the "intellectual property" asset, i.e. the software 
product, to which the license agreement and to 
which the protection technique are applicable, as a 
single software product or a set of software pro- 
ducts including their associated documentation 
65 which may be electronically delivered to the user 
as a unit or package. The contents of tiie package 
or unit are to be determined by tiie software origi- 
nator or distributor. 



4 



MST00006293 



7 



EP 0 367 700 A2 



The essential elements of the preferred em- 
bodiment in programming are provided by Uie soft- 
ware onginator as will be described in greater 
detail with reference to Figures 2 and 3. 

Turning to Rgure 2. a brief fiow chart is shown 
of the operation that will be conducted by the 
preferred embodiment contained within the deliv- 
ered data object when it is initialized and run on 
the recipient's computer or worl<-station. 

The first step as shown in Rgure 2 is for the 
system to access the files which contain the dis- 
play data for displaying the receipt and acceptance 
menu screens for the user's review. These will 
include a menu, license agreement terms and con- 
ditions and'or warranty terms and conditions and 
the like. 

The second step as shown in Rgure 2 Is to 
present choices to the user to accept or decline the 
terms and conditions which are displayed on the 
receipt and acceptance information screens. If non- 
acceptance is indicated by the user, the program 
aborts and returns to the operating system without 
altering the original object modules and files to 
render them into a usable state. However, if the 
user does indicate acceptance of the terms and 
conditions, the program continues as shown In 
blocks 1-5 as follows. 

In block 1. the program for enabling the object 
for use will search for the previously mentioned 
arbitrary character strings embedded in the original 
object file(s) by the originator thereof. These will 
then be modified, and, optionally, encrypted if so 
desired to contain information entered in response 
to prompts by the user or recipient that may also 
identify the specific user. 

Then the program will enable the electronically- 
delivered object by unscrambling (or decrypting) 
the scrambled pseudo file names by replacing 
them with the real file names. This is done using 
the table of correspondence that has been pre- 
viously provided in the data object by the origina- 
tor. This table cannot even be accessed or utilized 
by the enabling program unless the acceptance of 
the terms and conditions has been indicated by the 
user. 

As shown in block 3. the program may option- 
ally recalculate the check sum of the object being 
delivered, if a check sum is employed. 

As shown in block 4, the program for enabling 
then must modify itself to delete that portion of the 
code that provided for the enabling of the delivered 
object It also will delete the correspondence table 
and finally, in block 5, transfer control to the ob- 
jecfs initial startup module or file at the name 
indicated by the software originator. This activates 
the delivered object for use and operation. 

The detailed operation will now be described 
with reference to Figure 3 which shows ttie pro- 



- cessing or enabling program flow chart at the re- 
cipient or user's computer or workstation upon 
loading the received electronically-transmitted 
and'or magnetically-recorded data object (software 

5 product). The end user will insert, as shown in box 
1, his her diskette if the software product has been 
magnetically recorded and delivered or will request 
a download of Uie electronically-distributed soft- 
ware product from a host system to the hard or 

70 floppy disk drive of his/her computer or worksta- 
tion. The user will tiien invoke the initialization and 
enabling facility embedded in the software product 
by the originator by entering tiie command 
"goXXX" as shown in box 1. This command in- 

15 vokes tine enabling program. In box 1. ttie XXX 
portion is a unique identifier that identifies ttie 
name of ttie software product to be utilized. The 
enabling program is named '*go.COM" but will be 
renamed "PlJ\.COM" once tiie license agreement 

20 has been accepted by tiie user and the software 
product files have been unscrambled and renamed. 

The enabling program ttien displays tiie first 
originator's prescribed license andor warranty 
menu display screen to tiie user. This screen 

25 would nomially contain introductory information 
and describe how tfie terms and conditions will be 
presented to the user on following screens. The 
user would normally press tiie enter key to con- 
tinue to tine second or succeeding menu screens. 

30 The program then continues to box 2 to present a 
menu screen of user choices as shown. If the user 
chooses to read prescribed warranties (choice 1). 
the program exits box 2 and accesses warranty 
display screens (box 8) which, after being re- 

35 viewed, return the user to his block, if choice 2 is 
chosen tiie license agreement screens will be dis- 
played to the user and tiie system will continue as 
shown. If choice 3 is selected, tiien the system 
aborts witiiout enabling tiie software product for 

40 use and returns to the operating system. If any 
other key is pressed, a message will be displayed 
and a corect choice will be prompted from tiie 
user. 

If tiie license agreement screens are selected 
45 (choice 2). tiiey are displayed to tiie user utilizing 
whatever text for tiie license agreement the origina- 
tor has encoded into tiie software product. The 
user is prompted to indicate acceptance or rejec- 
tion of tiie terms and conditi'ons of tiie license 
50 agreement on the last screen thereof. If rejection is 
indicated, tiie system aborts and returns to tiie 
operating system witiiout enabling Uie software 
product for use. 

If acceptance is indicated, ttie system contin- 
55 ues on to box 3 by commencing tiie "accept PLA" 
program routine. The first step in box 3 is to search 
for for the correspondence table that shows the 
correspondence between tiie pseudo (scrambled) 
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file names and the actual software product file 
names. If there isn't such a table, the program then 
searches for the arbitrary character string embed* 
ded In major file(s} or module(s) by the product 
originator and modifies them as will be later dis- 
cussed on box 9. Secondly, if there ts a correspon- 
dence table, the program reads the table into 
memory and accesses the first row in the table to 
provide a correct file name for the module iden- 
tified therein instead of Its pseudo or scrambled 
name. The next step is to modify and/or encrypt 
the arbitrary character string If it is embedded in 
the major file or module being accessed. This 
process continues until all of the entries in the table 
have been exhausted, ail of the arbitrary ch^acter 
strings have been modified, and all of the cor- 
responding files or modules have been renamed to 
their correct names. An optional alternative follow- 
ing the completion of the above tasks is to recalcu- 
late a check sum (if that is used) as shown later in 
box 6. 

If there is a conrespondence table, the program 
continues to box 4 where the table processing 
routine checks to see if ail of the rows of the 
scrambled name table have been processed. When 
the rows have ail been processed, the table is 
erased as shown in box 5. Box 4 provides the 
ability for the program originator to require modi- 
fication and encryption of the character string in the 
files of the delivered data object. 

The "erase table" routine is shown in box 5 
and is entered from box 4 when all of the table 
entries have been processed- The enabling pro- 
gram then continues to box 6, which may optionally 
recalculate the check sum if provided with the 
software product, the enabling program continues 
to box 7 to erase the warranty screen from mem- 
ory and from the electronically-delivered software 
product The enabling program then modifies itself 
by erasing the code that allows the modification of 
the character strings and the file names, l.e. the 
unscrambling and renaming, and renames itself 
"PLA.COM" so that the license agreement screens 
can be recalled If desired; it then transfers control 
to box 11. 

Box 8 shows the optional warranty routine por- 
tion of the enabling program which is entered from 
box 2. 

Box 9 which is entered from box 3. is the 
character string routine that searches for ail files In 
the electronically-delivered software product that 
contain the character string placed there by the 
originator. It modifies (and/or encrypts) the string 
within these files and, when all of the accessed 
character strings have been found and modified, 
this portion returns to the acceptance routine in box 
3 above. Another purpose of this box 9 is to 
provide a further level of security on use of the 



product If the files which contain the ari^itrary 
character string do not contain the modified form 
which should have resulted from this box operation, 
then the software originator has an easy means for 

5 implementing an abort for disabling use of the 
code by simply including a test routine to test each 
file when it is accessed for the conrect character 
string. Testing for this use of these character 
strings by the software product itself is thus op- 

10 tional. 

Box 10 is invoked from box 4 in the flow chart 
and is the file finding portion of the enabling rou- 
tine, if the software originator has scrambled the 
original product file names, the files will not be 

15 usable until the license agreement has been ac- 
cepted by the user and the files have been un- 
scrambled. The pubfisher or originator has original- 
ly provided a table of cross-references between the 
pseudo file names and the actual file names. The 

20 routine ends in box 4 which is entered from box 3 
as noted previously. 

The enabling program ends finally in box 11 
which is entered from box 7 as noted previously. 
By handing control over to the batch file or installa- 

25 tion program name provided by the software origi- 
nator, the enabling program will then proceed to 
initialize the actual software product for use. 

It will be appreciated in the foregoing that the 
renaming or scrambling of the original files is first 

30 accomplished by the software originator and that 
the originator also provides, together with the 
scrambled file, the table of corresponding pseudo 
names or scrambled names with their correspond- 
ing actual file names. By this means the conrect file 

05 names may be restored by the enabling portion of 
the routine if it. in turn, is enabled by the user's 
acceptance of the license agreement terms and 
conditions. A "self-enabling" facility is thus built 
into the software product by the onginator. This 

40 facility is invoked, albeit somewhat unknowingly by 
the end user. In effect, the software product is 
rendered unusable, since internal references within 
code modules to use files or file names will not find 
the corresponding files or file names unless the 

,15 unscrambling process has been carried out pre- 
viously. The unscrambling process, in turn, will not 
be entered and cannot be invoked unless the user 
has indicated acceptance of the terms and con- 
ditions of the license agreement. The electronic 

so data object as delivered, i.e. the software product 
as provided by the originator, thus contains not 
only the software product program code but the 
enabling routine together with the necessary en- 
abling table and an appropriate set of screens and 
55 a small amount of control code to determine wheth- 
er the user has indicated acceptance or rejection of 
the license agreement screen information. If accep- 
tance IS indicated and the enabling routine is al- 
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lowed to proceed to completion, the routine then 
] erases the enabling portions of itself and the en- 
! abling table. It thus effectively destroys the "keys" 
j or "decryption technique" prior to granting access 
I or actual use of the software product to the user. 
' Also, the en abling program routine as described in 
the figures includes a step that encrypts or other- 
wise records information entered by the prospec- 
tive user so that it permanently "marks" the user's 
copy with information that could be later accessed 
by the program originator. This information may 
uniquely identify the user and his/her copy of the 
software product so that any unauthorized copies 
that are later detected may be traced back to their 
origin, it will thus be seen that a variety of security 
provisions, some of which are optional (i.e., the 
checksum calculation and testing within the soft- 
ware product itself for the modified character 
strings), may be easily included at the selection of 
the program originator while no special provision 
need be made or taken at the user's end to provide 
access to the delivered software product otiier than 
indication of acceptance of the terms and con- 
ditions which will invoke the enabling routine and 
. restore the software product to a usable form. 

Extension of Uiese concepts to a variety of 
other fields is clearly within the scope of this Inven- 
tion. For example, the electronically delivered data 
object need not be a program with license agree- 
ment screens but could be simply a certified mes- 
sage or legal document receipt of which is desired 
in a verified manner. A verification statement and 
acceptance screen, acceptance of which will be 
indicated by the user, can be utilized to access an 
acknowledgement transmission back to the sender 
that will occur if and only if the recipient agrees to 
receive the message. By a similar obvious exten- 
sion, the content might not be either a license 
agreement or a message but could be a contract, a 
bill of lading, or any other document of legal signifi- 
cance certified receipt and acceptance of which is 
desired. 

Having thus described our invention with re- 
spect to a prefenred embodiment as implemented 
in simpie program routines, it will be obvious to 
those of skill in tfie art that many modifications and 
enhancements are possible witiioul departing from 
the basic concepts of tfie self-enabling, self-verify- 
ing process of the routine as described in the 
preferred embodiment. Therefore, what is intended 
to be protected by way of letters patent is set fortii 
in the following claims as description and not limi- 
tation. 



Claims 

1. A method of verifying receipt and accep- 



tance of a data object delivered 7rom a sender to a 
receiver characterized by the steps of: 
modifying said data object into an unusable form; 
and inserting an enabling means into said data 
5 object, 

delivering said data object to said receiver in said 
unusable form, and 

employing said enabling means to remodify said 
data object back to a usable form. 
w 2. The method of Claim 1 wherein: 

said modifying step furUier comprises inserting a 
verification indicia into said data object, and 
employing said enabling means modifies said indi- 
cia. 

Ts 3. The method of Claim 1 or 2. wherein: 

said modifying step further comprises substituting 
new names for existing file component names in 
said data object and recording tiie correspondence 
between said new names and said existing names 

20 as a portion of said data object aj a location acces- 
sible only by sad enabling means. 

4. The method of Claim 3. wherein: 

said step of employing said enabling means further 
compnses steps of accessing said recording of 
25 names corre spondence and restoring said original 
names as file component names, erasing said 
record of names con'espondence and said enabling 
means. 

5. A system for verifying receipt and accep- 
^0 tance of a data object in an information commu- 
nication system, including a sender and a receiver, 
said sender and receiver being physically sepa- 
rated Prom one anottier, and including means at 
said sender for preparing said data object for deiiv- 

35 ery to said receiver and a data delivery means for 
delivering said data object from said sender to said 
receiver, said system being characterized in that it 
comprises: 

means at said sender for modifying said data ob- 
40 ject for delivery, said modifying rendering said ob- 
ject into an unusable and/or inoperative state, 
means at said sender for inserting an enabling 
means Into said data object prior to delivery there- 
of, 

4$ means at said receiver for loading said modified 
data object into a computer for display and for 
operations thereon, 

means for initially accessing only said enabling 
means in said data object and for displaying por- 
50 tions of data contained tfierein for soliciting a user's 
response thereto. 

means for entering a user's response and means 
for recording said response, 
means conditioned by said response for employing 
55 said enabling means and modifying said data ob- 
ject back to a usable and/or operative state. 

6. The system as described in Claim S, further 
comprising: 
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means at said sender for inserting a venficabon 
indicra into said data object, and 
means at said receiver for modifying said venfica- 
tion indicia in response to sad user's response. 

7. The system as described m Claim 5 or 6, 
wherein said receiver includes means responsive to 
said enabling means for erasing said enabling 
means responsive to said user's response. 

8. The system as described in Claim 5 or 6. 
wherein said means for modifying comprises 
means for replacing original component names in 
said data object with other names not used by said 
data object, and further comprising 
recordlceeping means for recording the correspon- 
dence between replacement component names 
and original component names and for inserting 
said record thereof into said data object. 

9. The system as described in Claim 6, 
wherein said means for modifying said verification 
indicia modifies said indicia in a manner which 
shows that said enabling means has been em- 
ployed to remodify said data obiect. 

10. The system as descnbed in Claim 5, 6 or 
9. wherein said enabling means erases portions of 
itself from said data object 
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FIG. 1A 



FIG. 1 



FIG. 
lA 

FIG. 
IB 



INTERFACE/FUNCTION 


NOTES 


PROVIDE TEXT FOR THE LICENSE 
AGREEMENT SCREEN(S). ON THE 
LAST SCREEN OF THE LICENSE 
AGREEMENT. THE USER MUST 
INDICATE ACCEPTANCE OR RE- 
JECTION OF THE TERMS AND 
CONDITIONS BEFORE THE 
OBJECT OR SOFTWARE PRODUCT 
WILL BE INSTALLED. 




INSERT A PREDEFINED CHARACTER 
STRING INTO THE PRODUCT'S 
MAJOR MOOULE(S)/FlLE(S). 
THIS CHARACTER STRING MAY BE 
MODIFIED AND/OR ENCRYPTED 
AFTER THE LICENSE AGREEMENT 
HAS BEEN ACCEPTED BY THE USER. 
MODIFICATION OF THE 
CHARACTER STRING INDICATES 
THAT THE USER HAS ACCEPTED 
THE TERMS AND CONDITIONS 
OF THE LICENSE AGREEMENT. 


THERE MUST BE AT LEAST 
ONE FILE WHICH CONTAINS 
THE CHARACTER STRING. 


CREATE THE COPY OF THE 
PRODUCT OR OBJECT WITH 
THE FILENAMES "SCRAMBLED AND 
GIVEN PSEUOO NAMES. ALSO. 
PROVIDE A TABLE WHICH 
CROSS REFERENCES THE 
PSEUDO (SCRAMBLED) FILE- 
NAMES WITH THE REAL 
FILENAMES. 


THE FILENAMES WILL NOT 
BE RESTORED (i.e., THE SOFT- 
WARE PRODUCT WILL NOT BE 
USEABLE) UNTIL THE 
LICENSE AGREEMENT HAS 
BEEN ACCEPTED BY THE USER 
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• 


INSERT A TEST ROUTINE INTO THE , 
CODE OF EACH OF THE SOFTWARE 
PRODUCT MODULES/FILES CON- 
TAINING THE CHARACTER STRING 
TO ALLOW EXECUTION OF THE 
MODULE(S) AFTER INSTALLATION 
ONLY IF THE STRING HAS BEEN 
MODIFIED (i.e.. THE LICENSE 
AGREEMENT HAS BEEN ACCEPTED 
BY THE USER). 


THE IMPLEMENTATION OF THIS 
OPTIONAL FEATURE BY THE 
SOFTWARE PUBLISHER 
PROVIDES ANOTHER LEVEL 
OF ASSET PROTECTION. 


PROVIDE THE LOCATION IN THE 
SOFTWARE PRODUCT MODULE/FILE 
FOR THE CHECKSUM WHICH WILL 
BE RECALCULATED UPON ACCEPT- 
ANCE OF THE LICENSE AGREEMENT 
AND COMPLETION OF THE 
PROCESSING PROGRAM. 


THE IMPLEMENTATION OF THIS 
OPTIONAL FEATURE BY THE 
SOFTWARE PUBLISHER 
PROVIDES ANOTHER LEVEL 
OF ASSET PROTECTION. 


PROVIDE A BATCH FILE PROGRAM 
OR INSTALLATION PROGRAM TO 
WHICH CONTROL WILL BE 
TRANSFERRED AT THE COMPLETION 
OF THE ACCEPTANCE VERIFICATION 
ENABLING PROGRAM AFTER THE 
USER HAS INDICATED ACCEPTANCE 
OF THE LICENSE AGREEMENT. 


THIS LINK PROVIDES THE 
TRANSFER BETWEEN THE 
RECEIPT AND ACCEPTANCE 
ENABLING PROCESSING 
PROGRAM AND THE SOFT- 
WARE PRODUCT. 



FIG. 1B 
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fig: 2 

PRESENT THE APPLICABLE TERMS AND CONDITIONS 
TO THE USER BY DISPLAYING THE FOLLOWING: 



RECEIPT AND ACCEPTANCE MENU SCREENS (MAY 
INCLUDE MENU. WARRANTY AMD LICENSE 
AGREEMENT SCREENS) 



IF THE USER DOES NOT ACCEPT THE TERMS AND 
CONDITIONS DISPLAYED BY RECEIPT AND 
ACCEPTANCE SCREENS. ABORT AND RETRUN TO 
THE ORIGINAL OBJECT MODULES/ FILES. 
DO NOT ACTIVATE INSTALLATION OF THE 
OBJECT. 

ELSE 

CONTINUE. 



1. SEARCH FOR THE CHARACTER STRING, AND 
MODIFY (AND ENCRYPT) THE STRING 
INSERTED BY THE OBJECT ORIGINATOR 
INTO THE OBJECT'S MAJOR FILE(S) 



ENABLE THE OBJECT BY UNSCRAMBLING AND/OR 
DECRYPTING PSEUDO FILENAMES TO THE REAL 
FILENAMES USING THE TABLE PROVIDED BY 
THE OBJECT ORIGINATOR. 



3. RECALCULATE THE OBJECT'S CHECK- 
SUM USING THE CHECKSUM LOCATION 
PROVIDED BY THE ORIGINATOR. 
(OPTIONAL FEATURE). 



4. MODIFY THE RECEIPT AND ACCEPTANCE PROGRAM 
ITSELF BY DELETING THE CODE THAT PROVIDES 
FOR MODIFICATION OF THE OBJECT'S FILE(S) 



5. ACTIVATE THE OBJECT FOR USE OR DISPLAY BY 
TRANSFERRING CONTROL TO THE OBJECT 
MODULE/FILE NAME PROVIDED BY THE OBJECT 
ORIGINATOR. 
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START-OF-PLA-PROCEDURE: 



FIG, 3A 



THE END USER INSERTS DISKETTE #1 OF X (OR 
DOWNLOADS THE PRODUCT TO THE HARD DISK), 
SELECTS THE CORRECT DRIVE. AND TYPES 
"GOXXr (RETURN) AT THE SYSTEM PROMPT. 

"GOXXX" INVOKES CO. COM, THE ENABLING 
PROGRAM 



IB 



DISPLAY FIRST LICENSE AND/OR WARRANTY 
MENU SCREEN TO THE USER. IT CONTAINS 
INTRODUCTORY INFORMATION AND 
DESCRIBES HOW THE TERMS AND CONDITIONS 
WILL BE PRESENTED TO THE USER. 



CUSTOMIZED TEXT 



THE USER PRESSES THE ENTER KEY TO 
CONTINUE TO THE SECOND MENU SCREEN. 



2A 



MENU-SELECTION- 
ROUTINE 



FROM THIS MENU SCREEN, THE USER CAN 
SELECT TO (1) READ THE WARRANTY 
INFORMATION PRIOR TO ACCEPTING THE 
T'S AND C'S OR THE LICENSE AGREE- 
MENT, (2) READ THE LICENSE AGREEMENT 
OR (3) ABORT AND RETURN TO THE 
OPERATING SYSTEM. 

IF CHOICE - 1, THEN PERFORM WARRANTY- 
ROUTINE (BOX 8). 

IF CHOICE - 2. THEN CONTINUE TO NEXT BOX. 

IF CHOICE - 3. THEN ABORT AND RETURN TO 
THE OPERATING SYSTEM. 



I 
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FIG. 3B 



THE LICENSE AGREEMENT SCREEN(S) ARE 
DISPLAYED TO THE USER. 



CUSTOMIZED TEXT 



FOR MULTIPLE-SCREEN AGREEMENTS. THE 
USER PRESSES THE ENTER KEY TO GO 
FROM SCREEN TO SCREEN UNTIL THE 
LAST SCREEN. THE USER CAN ALSO PAGE 
FORWARD AND BACKWARD WITHIN THE 
AGREEMENT SCREENS. 

ON THE LAST SCREEN OF THE AGREEMENT. 
THE USER IS ASKED TO INDICATE HIS/HER 
ACCEPTANCE OF THE T'S AND C'S OF THE 
LICENSE AGREEMENT. 

IN "H" IS INDICATED. THEN ABORT AND 
RETURN TO THE OPERATING SYSTEM. IF 
'T' IS INDICATED, THEN CONTINUE TO 
BOX 3 
ELSE 

REQUEST CORRECT RESPONSE AND DO 
NOT PROCEED UNTIL CORRECT RE- 
SPONSE IS ENTERED. 



ACCEPT-PLA- 
Tl ROUTINE ^ 

THE CHARACTER STRING IN THE OBJECT'S 
MAJOR FILE(S5 IS MODIFIED IF THE 
LICENSE AGREEMENT HAS BEEN ACCEPTED. 
IF THERE IS A PLA.TAB FILE ON THE DISK/ 
DISKETTE. THEN 

READ PLA. TAB INTO MEMORY 
POSITION TO THE FIRST ROW IN THE 
TABLE CONTINUE TO BOX 4. 
ELSE 

PERFORM CHARACTER-STRING-ROUTINE 
(BOX 9) 

GOTO CHECKSUM-ROUTINE (BOX 6). 



I 
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PROCESB-TAB- 
• ROUTINE 



I 



IF ALL ROWS OF PLA.TAB HAVE BEEN PRO-' 
CESSED. THEN GOTO ERASE-TAB 
ROUTINE (BOX 5). 

ELSE 

PERFORM FIND-FILE-ROUTINE (BOX 10) 
IF COL 2 OF PLA.TAB - THEN 

MODIFY AND ENCRYPT THE SPECIAL 
STRING IN THE FILE ON THE DISK/ 
DISKETTE 
GOTO RENAME-ROUTINE. 
ELSE 

CONTINUE TO NEXT BOX, 



4B 



RENAME-ROUTINE 



RENAME THE FILE ON THE DISK/DISKETTE 
FROM THE PSEUDO FILENAME (FROM COL 
XX OF PLA.TAB) TO THE REAL FILENAME 
(FROM COL YY OF PLA.TAB). 

POSITION TO THE NEXT ROW IN PLA.TAB. 

GOTO PROCESS-TAB-ROUTINE (BOX 4). 



ERASE-TAB- 
"Tl ROUTINE 



FIG.3C 



IF G0.COM AND PLA.TAB ARE ON THIS DISK/ 
DISKETTE, THEN 

ERASE PLA.TAB FROM MEMORY AND FROM 

THE DISK/DISKETTE 
GOTO CHECKSUM-ROUTINE (BOX 6). 

ELSE 

REQUEST THE USER TO INSERT DISKETTE 
#1 AND TO PRESS THE ENTER KEY 

REPEAT ERASE-TAB-ROUTINE UNTIL G0.COM 
AND PLA.TAB ARE FOUND. 



CHECKSUM- 
'~6l ROUTINE 



I 



IF CHECKSUM IS NOT USED, THEN CONTINUE 

TO BOX 7. 

ELSE 

RECALCULATE CHECKSUM ON THE 
DISK/DISKETTE. 
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FIG.3D 



ERASE THE WARRANTY SCREEN(S) FROM 

MEMORY AND FROM THE DISK/DISKETTE. 
MODIFY G0.COM BY ERASING THE CODE 

THAT ALLOWS MODIFICATION OF THE 

PROGRAM MODULES/FILES. 
RENAME THE MODIFIED (SMALLER) 

G0.COM TO PLA. COM IW 

MEMORY AND ON THE DISK/ 

DISKETTE. 
GOTO END-OF-PLA-PROCEDURE (BOX 11). 



WARRANTY- 
ROUTINE 



i 



THE OBJECT'S WARRANTY SCREEN(S) ARE 
DISPLAYED TO THE USER. 



CUSTOMIZED TEXT 



FOR MULTIPLE-SCREEN WARRANTIES. THE 
USER PRESSES THE ENTER KEY TO GO 
FROM SCREEN TO SCREEN UNTIL THE LAST 
SCREEN. THE USER CAN ALSO PAGE 
FORWARD AND BACKWARD WITHIN THE 
WARRANTY SCREENS. 



AFTER READING THE LAST SCREEN. THE 
USER IS INSTRUCTED TO PRESS THE 
ENTER KEY TO RETURN TO THE WARRANTY 
AND LICENSE MENU SCREEN (#2 OF 2) SO 
THAT HE/SHE CAN THEN SELECT TO 'READ 
THE LICENSE AGREEMENT. 

RETURN TO MENU-SELECTION-ROUTINE 
(BOX 2). 
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CHARACTER- 
STRING-ROUTINE 



I 



FIND ALL THE FILES OF THE OBJECT (EXCEPT 
FOR G0.COM) THAT CONTAIN THE SPECIAL 
STRING. MODIFY AND ENCRYPT THE SPECIAL 
STRING IN THE FILE(S). 

IF THE OBJECT IS ON DISKETTE. THEN LOOK 
ONLY ON DISKETTE #1 FOR THE FILES (EXCEPT 
FOR G0.COM) AND MODIFY AND ENCRYPT THE 
SPECIAL STRING IN THE FILE(S) ON 
DISKETTE #1. 

WHEN THE STRINGS IN ALL THE REQUIRED 
FILES HAVE BEEN MODIFIED. RETURN TO 
ACCEPT-PLA-ROUTINE (BOX 3). 



10 



FIND-FILE- 
ROUTINE 



I 



IF THE PSEUDO FILENAME (FROM COL XX OF 
PLA.TAB) IS ON THIS DISK/DISKETTE. THEN 
RETURN TO PROCESS-TAB-ROUTINE (BOX 4). 

ELSE 

REQUEST THE USER TO INSERT DISKETTE #X 
(FROM COL 1 OF PLA.TAB) AND TO PRESS 
THE ENTER KEY 

REPEAT FIND-FILE-ROUTINE UNTIL THE 

FILE IS LOCATED. 



11 



END-OF-PLA- 
PROCEDURE 



I 



GOTO THE INSTALLATION PROCEDURE FOR THE| 
OBJECT BY TRANSFERRING CONTROL TO THE 
BAT FILE OR INSTALL PROGRAM NAME 
PROVIDED BY THE SOFTWARE PUBLISHER. 



STOP 



FIG. 3E 



FIG. 3 
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® The method of the invention consists, for the 
sender of a data object, first modifying the object 
into an unusable form and inserting into it a verificar 
tion Indicia and an enabling facility which is capable 
of rendering the data object Into an operative state 
when certain prerequisite conditions are met The 
receiver or user Inserts the data object into a work- 
station to view portions of the enabling facility, and 
then enters his acceptance or rejection of terms and 
conditions relating to the use and instailatjon of the 
data object in response to prompts that are pre- 
sented by the enabling facility. If the prerequisite 
conditions are met and agreed to, the data object is 
rendered into a usable and operable data fonm. 



FIG. 2 



PRESENT THE APPLICABLE TERMS AND CONDITIONS 
TO THE USER 8Y OlSPLATtNG THE FOLLOWING: 



RCCeifT AND ACCCPTANCC MENU SCREENS (MAY 
INCLUDE MENU* WARRANTY AND LICENSE 
AGREEMENT SCREENS) 



IF THE USER DOES NOT ACCEPT THE TERMS AND 
CONDITIONS DISPLAYED BY RECEIPT AND 
ACCEPTANCE SCREENS. ABORT AND RETRUN TO 
THE ORIGINAL OBJECT MODULES/ FILES. 
DO NOT ACTnwre INSTALLATION OF THE 
OBJECT. 

ELSE 

CONTINUE. 



1 SEARCH FOR THE CHARACTER STRING. ANO 
MODIFY (AND ENCRYPT) THE STRING 
INSERTED BY THE OBJECT ORICINATOR 
INTO THE OBJECTS MAJOR FtLECS> 



-2. ENABLE THE OBJECT BY UNSCRAMBLING ANQ/OR 
DECRYPT IMC PSEUDO FILENAMES TO THE REAL 
FILENAMES USING THE TABLE PROVIOEO BY 
THE OBJECT ORIGINATOR. 



3. RECALCULATE THE OBJECT'S CHECK- 
SUM USING THE CHECKSUM LOCATION 
PROVIDED BY THE ORIGINATOR. 
(OPTIONAL FEATURE). 



4. MODIFY THE RECEIPT AND ACCEPTANCE PROGRAM 
ITSELF BY DELETING TH£ CODE THAT PROVIDES 
FOR MODirrCATION OF THE OBJECT'S FILECSI. 



5. ACTIVATE THE OBJECT FOR USE OR DISPLAY BY 
TRANSFERRING CONTROL TO THE OBJECT 
MODULE/FILE NAME PROVIDED BY THE OBJECT 
ORIGINATOR. 
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Description 

This invention relates to receipt and acceptance 
verification techniques for documents, license agree- 
ments, contracts, or computer programs generally, and 
more specificaliy, it relates to a method for verifying re- 
ceipt and acceptance of electronically transmitted 
and/or magnetically recorded data objects. 

While a variety of prior art techniques exist for pro- 
tecting electronically transmitted and/or magnetically- 
recorded data objects, all of these that are presently 
known require either encryption and the use of a de- 
crypting key or algorithm which is normally only availa- 
ble to a previously authorized recipient, or they require 
prior approval for sending to the recipient. Other than by 
these techniques, no present system or technique is 
known which is self-verifying as to the fact that the re- 
cipient has actually received the data object, agreed to 
the authorization conditions of its receipt or use and in- 
stalled it for reading or use. 

In the field of computer program products. Le. "soft- 
ware", unauthorized duplication and/or access and us- 
age is a common problem. U.S. Patent 4,757.534 shows 
one example of a cryptographic technique for protecting 
such programs. The user must have a password which 
will allow the encrypted program to be recovered at a 
prescribed and designated site that has a properly im- 
plemented and initialized decryption feature. 

Similariy. U.S. Patent 4,757,533 deals with a secu- 
rity system for a personal computer which utilizes auto- 
matic encryption and decryption for files in the personal 
computer. 

US patent 4 649 51 0 deals with a method for pro- 
tecting computer programs which requires the transmis- 
sion of a modified program and of a restoration program 
and acceptation data through different channels and 
which also needs the use of passwords. 

These prior art systems, and others of similar type, 
require the prearranged installation of encryption or de- 
cryption features and/or "keys" such as passwords be- 
fore a user or recipient can utilize an electronically-de- 
livered or magnetically-recorded and delivered data ob- 
ject that has been protected by encryption or other dis- 
abling techniques. This is a significant drawback in the 
field of computer programing sales and use, particularly 
in systems which would download application programs 
for use at a local workstation or personal computer/sys- 
tem. In the latter instance, the program or data object 
would be electronically transmitted and received, but 
elaborate systems are used to preauthorize the recipi- 
ent by g'rving passwords or the like which must be care- 
fully recorded and kept track of for accounting purposes 
and for billing. 

In light of the foregoing known shortcomings with 
the prior art systems and techniques for electronic dis- 
tribution of data objects, the object of the present inven- 
tion is to provide an improved method and a system of 
securing electronic data objects and for verifying that 



they have been received and' accepted which do not re- 
quire prior authorization for receipt or the Installation of 
previously authorized and released keys, passwords or 
the like. 

s The system -according to the subject invention as 
claimed in claim 1 is used for verifying receipt and ac- 
ceptance of a data object in an infonmation communica- 
tion system. 

The method according to the present Invention as 
10 set out in claim 7 is used for verifying receipt and ac- 
ceptance of a data object delivered from a sender to a 
receiver. 

The invention will now be described with respect to 
a preferred embodiment in reference to the accompa- 
15 nying drawings wherein: 

Figure 1 is a brief flow chart of steps taken by the 
data object originator or sender prior to sending or de- 
livering the data object to a user. 

Figure 2 is a brief flowchart illustrating the operation 
20 of the invention at the recipient or user's workstation or 
computer. 

Figure 3 illustrates a detailed processing flow chart 
of the operation of the Invention at the recipient or user's 
workstation or computer. 

2S The invention will be described with reference to the 
figures in the exemplary context of a system for deliver- 
ing computer programs (software products) having li- 
cense terms and conditions that must be agreed to prior 
to the user's being granted use of his or her copy of the 

30 software product. Numerous other examples are possi- 
ble, any of which relate generally to the problem of ver- 
ifying that a recipient has actually received a data object 
and has agreed to certain terms and conditions con- 
cerned therewith. Other examples may be documents 

35 that nonnally require registered and signed receipt mail 
delivery, contracts or other documents having legal sig- 
nificance, itemized buying and selling an-angements, 
bills of lading, or any environment in which a traceable 
record (within the data object itself) of actual receipt and 

40 acceptance of the data object is required. 

In the preferred embodiment of the invention de- 
scnlDed, an example chosen from the field of data 
processing is given. In this example, the "data object" 
may be a computer program (software product) intend- 

45 ed for use on a workstation or personal computer/sys- 
tem. In such an environment, the normal users wish to 
obtain their copy of the relevant software product, carry 
it home (or to their woricstations) and use it Normally 
these software products are accompanied by a "shrink 

so wrapped" license agreement which details the terms 
and conditions of use which the buyer, or more appro- 
priately, the "licensee" is deemed to be bound by virtue 
of his or her opening and use of the contents of the pack- 
age. If high security over unauthorized duplication or us- 

55 age of programs is desired in such an environment, de- 
tailed record keeping via serialization of the software 
product, signed receipts obtained at the time of pur- 
chase or license, detailed record keeping and auditing 
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procedures and the like are often necessary. These are 
expensive and time consuming. 

It would be far more desirable in today's electronic 
communication environment to provide software prod- 
ucts at a central access point which could be accessed 5 
on request, and whose contents could be made availa- 
ble to or even downloaded for users on request. Since 
the users may come and go and since access to the 
central facility may be difficult or cumbersome to regu- 
late, it would be more desirable still If any potential user 
could merely "dial up" the central facility and request ac- 
cess to and delivery of any given software product. This 
would mean that prior authorization procedures, i.e. de- 
livery of decryption or security keys or codes or routines 
would not be ordinarily possible or even desirable. Ad- 
ditionally in order to overcome the relatively high cost of 
creating diskettes or cassettes of recorded software 
products for delivery, the electronic distribution and du- 
plication method holds high market appeal but offers as 
well the opportunity for more prevalent abuse through 
unauthorized access, copying, and/or use. 

Into this environment, the present Invention fits 
nicely as a solution to the problem; this invention may 
be implemented within the electronic data object itself 
and which is self-executing upon its receipt and accept- 
ance by a user or requester. 

The preferred embodiment will thus be described in 
the context of a system for delivery via electronic means 
of computer programs (software products) which pro- 
vide automatic verification that the requester or recipient 
has actually received the software product and has 
agreed to the temns and conditions regarding its use. 

The present invention provides a technique for the 
protection of electronically-distributed software prod- 
ucts which are to be licensed to requesting end users 
who have not previously been authorized or provided 
with any specialized access keys or decryption pro- 
grams or devices. The technique itself is based upon 
the premise that both the usability and installabllity of 
electronically-delivered software products may be con- 
ditioned upon the end user's receipt and acceptance of 
the terms and conditions regarding the specific software 
product. A license agreement of the readable form nor- 
mally enclosed with recorded diskettes or cassettes is 
incorporated into the electronically-delivered data ob- 
ject or software product and is delivered therewith. The 
invention presents to the user the ternos and conditions 
regarding the use, charges for and other relevant data 
pertaining to the software product for the user's review 
and acceptance or rejection. The invention presents 
prompts or questions to the user and records the re- 
sponses as evidence that a user did receive, and has 
or has not agreed, to the terms and conditions regarding 
the software product. If the user does agree to the terms 
and conditions and so indicates, the invention provides 
for "enabling" the delivered disabled and unusable soft- 
ware product. It also provides for marking that user's 
copy with indicia which indicates acceptance and may 



also determine the identity of the user. The invention 
thus provides the electronic equivalent of "breaking of 
the shrink wrap seal" involved in the normal hard copy 
of software license agreements delivered with physical 
diskettes or cassettes. It replaces prior authorizations 
via signed agreements which are prearranged in elec- 
tronic distribution systems which require that potential 
users first sign up and agree to the license agreement 
terms and conditions in order to receive a decryption key 
or password which will grant them access to the desired 
software products. 

The Invention requires some preparation on the part 
of the software product originator or sender. As shown 
in Figure 1. the software product originator is required 
to include with the software product, or electronically- 
deliverable data object, modules of code that provkJe a 
presentation and acceptance verification and enabling 
facility (enabling program). The software product origi- 
nator is further required to provide certain input to the 
enabling program. The originator must provide the lan- 
guage of the pertinent terms and conditions of the li- 
cense agreement by recording them as screen or output 
display code that will be accessed automatically by the 
enabling program. An appropriate prompt as to accept- 
ance or rejection of the terms and conditions of the li- 
cense agreement may also be provided In this data by 
the originator. In addition, the originator must insert an 
arisitrary predefined character string of the originator's 
own choosing into the software product's major module 
(s) or file(s). This arbitrary character string which may 
be called a "verification indicia" may be recognized by 
the software product itself as will be described later. It 
also will be modified and/or encrypted after the license 
agreement has been read and accepted by the user to 
indicate that the user has accepted the terms and con- 
ditions of the license agreement as will be later de- 
scribed. 

It is also incumbent upon the originator of the soft- 
ware product to create a copy of the software product 
with the pertinent file names or module names given 
"pseudo names" which are scrambled and to provide a 
table with cross references showing the correspond- 
ence between the pseudo or scrambled file names and 
the actual file names of the software product These ac- 
tual file names will not be restored and the software 
product itself will not be a usable program. The enabling 
program will restore the actual file names and unscram- 
ble the contents in response to acceptance by the user 
of the terms and conditions accompanying the software 
product. 

The originator of the software product must as not- 
ed eariier. provide a copy of the unscrambling and ena- 
bling facility. This is a short program routine as will be 
illustrated later. Finally, the originator should provide a 
batch file or installation routine to which control may be 
transferred at the completion of the acceptance and ver- 
ification process after the user has indicated his or her 
acceptance of the terms and conditions regarding use 
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of the software product. 

Before proceeding to a detailed description of the 
overall operation that occurs for enabling the software 
product for use at the user's computer or workstation, 
the basic concepts are summarized as follows: s 

The programs, which are the preferred embodiment 
of this invention, are incorporated into and become an 
integral part of the software product to be actually deliv- 
ered. This portion of the invention actually presents the 
applicable tenms and conditions of a license agreement io 
to the end user by displaying license agreement screens 
as the initial step during the installation process of the 
software product on the user's system. If the end user 
does not indicate acceptance of the terms and condi- 
tions of the applicable license agreement, the enabling 
program portion of the invention will abort operation, 
make no modifications to render the associated soft- 
ware product usable and m\\ return control to the user's 
operating system. In effect, 'no harm' has been done 
and the end user can follow whatever procedures are 
desired for retuming the effectively "unopened" soft- 
ware product or can destroy it as applicable. If, however, 
the user does indicate acceptance of the terms and con- 
ditions of the applicable license agreement, the portion 
of the preferred embodiment code will take additional 2S 
actions. It will electronically record the user's accept- 
ance by modifying certain predefined fields within the 
software product's applicable module(s) and file(s). It 
will also restore the original file names thereof, to allow 
them to be usable again, thus rendering the formerly un- 30 
usable program into a usable state. And it will modify 
itself, finally, by deleting the code portions which allowed 
unscrambling or decryption and reconstruction of the 
delivered software product and will hand control over to 
the installation module or startup routine of the software 
product. 

The primary advantage of this new system of secu- 
rity and dePfvery is that it essentially makes electronically 
distributed programs "Self protecting". It facilitates easy 
customization of license provisions and/or warranty in- 40 
formation and provides a wide range of asset protection 
mechanisms usable at the discretion of the software 
product originator. Those skilled in the art \mU realize 
that, within the scope of this invention, it is possible to 
redefine the 'intellectual properly" asset, i.e. the soft- 4S 
ware product, to which the license agreement and to 
which the protection technique are applicable, as a sin- 
gle software product or a set of software products in- 
cluding their associated documentation which may be 
electronically delivered to the user as a unit or package, so 
The contents of the package or un it are to be determined 
by the software originator or distributor. 

The essential elements of the preferred embodi- 
ment in programming are provided by the software orig- 
inator as will be described in greater detail with refer- ss 
ence to Figures 2 and 3. 

Turning to Figure 2, a brief flow chart is shown of 
the operation that will be conducted by the preferred enrv" 



bodiment contained within the delivered data object 
when it Is initialized and run on the recipient's computer 
or work-station. 

The first step as shown in Figure 2 is for the system 
to access the flies which contain the display data for dis- 
playing the receipt and acceptance menu screens for 
the user's review. These will include a menu, license 
agreement tamns and conditions and/or warranty terms 
and conditions and the like. 

The second step as shown in Figure 2 is to present 
choices to the user to accept or decline the terms and 
conditions which are displayed on the receipt and ac- 
ceptance information screens. If non^cceptance is in- 
dicated by the user, the program aborts and returns to 
the operating system without altering the original object 
modules and files to render them into a usable state. 
However, If the user does indicate acceptance of the 
terms and conditions, the program continues as shown 
in blocks 1 -5 as follows. 

In block 1 , the program for enabling the object for 
use will search for the previously mentioned aribltrary 
character strings embedded in the original object file(s) 
by the originator thereof. These will then be modified, 
and, optionally, encrypted if so desired to contain infor- 
mation entered in response to prompts by the user or 
recipient that may also identify the specific user. 

Then the program will enable the electronically-de- 
livered object by unscrambling (or decrypting) the 
scrambled pseudofile names by replacing them with the 
real file names. This is done using the table of corre- 
spondence that has been previously provided in the da- 
ta object by the originator. This table cannot even be 
accessed or utilized by the enabling program unless the 
acceptance of the tenms and conditions has been indi- 
cated by the user. 

As shown in block 3, the program may opttonally 
recateulate the check sum of the object being delivered, 
if a check sum is employed. 

As shown in block 4, the program for enabling then 
must modify itself to delete that portion of the code that 
provkjed for the enabling of the delivered object. It also 
will delete the correspondence table and finally, in bbck 
5, transfer control to the object's initial startup module 
or file at the name indicated by the software originator. 
This activates the delivered object for use and opera- 
tion. 

The detailed operation will now be described with 
reference to Figure 3 which shows the processing or en- 
abling program flow chart at the recipient or user's com- 
puter or wori^station upon loading the received electron- 
ically-transmitted and/or magnetically-recorded data 
object (software product). The end user will insert, as 
shown in box 1. his/her diskette if the software product 
has been magnetically recorded and delivered or will re- 
quest a download of the electronically-distributed soft- 
ware product from a host system to the hard or floppy 
disk drive of his/her cornputer or workstation. The user 
will then invoke the initialization and enabling facility em- 
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bedded in the software product by the originator by en- 
tering the command "goXXX" as shown In box 1. This 
command invokes the enabling program. In box 1, the 
XXX portion Is a unique identifier that identifies the name 
of the software product to be utilized. The enabling pro- 5 
gram is named "go.COW but will be renamed "PLA. 
COM" once the license agreement has been accepted 
by the user and the software product files have been 
unscrambled and renamed. 

The enabling program then displays the first origi- io 
nator's prescribed license and/or warranty menu display 
screen to the user. This screen would normally contain 
introductory information and describe how the terms 
and conditions will be presented to the user on following 
screens. The user would normally press the enter key is 
to continue to the second or succeeding menu screens. 
The program then continues to box 2 to present a menu 
screen of user choices as shown. If the user chooses to 
read prescribed warranties (choice 1 ). the program exits 
box 2 and accesses warranty display screens (box 8) 20 
which, after being reviewed, return the user to his block. 
If choice 2 Is chosen the ifcense agreement screens will 
be displayed to the user and the system will continue as 
shown. It choice 3 is selected, then the system aborts 
without enabling the software product for use and re- 
turns to the operating system. If any other key is 
pressed, a message will be displayed and a correct 
choice will be prompted from the user. 

If the license agreement screens are selected 
(choice 2), they are displayed to the user utilizing what- so 
ever text for the license agreement the originator has 
encoded into the software product. The user is prompt- 
ed to indicate acceptance or rejection of the terms and 
conditions of the license agreement on the last screen 
thereof. If rejection is indicated, the system aborts and 3S 
returns to Xhe operating system without enabling the 
software product for use. 

If acceptance is indicated, the system continues on 
to box 3 by commencing the "accept PLA" program rou- 
tine. The first step in box 3 is to search for for the cor- <o 
respondence table that shows the correspondence be- 
tween the pseudo (scrambled) file names and the actual 
software product file names. If there Isn't such a table, 
the program then searches for the arbitrary character 
string embedded in major file(s) or module(s) by the 4S 
product originator and nnodifies them as will be later dis- 
cussed on box 9. Secondly, if there is a correspondence 
table, the program reads the table into memory and ac- 
cesses the first row in the table to provkje a con'ect file 
name for the module identified therein instead of its so 
pseudo or scrambled name. The next step is to modify 
and/or encrypt the arbitrary character string if it is em- 
bedded in the major file or module being accessed. This 
process continues until all of the entries in the table have 
been exhausted, all of the arbitrary character strings ss 
have been modified, and all of the corresponding files 
or modules have been renamed to their correct names. 
An optfonal alternative following the completion of the 



;above tasks is to recalculate a check sum (if that is used) 
fas shown later in box 6. 

If there is a correspondence table, the program con- 
tinues to box 4 where the table processing routine 
checks to see if all of the rows of the scrambled name 
table have been processed. When the rows have all 
been processed, the table is erased as shown in box 5. 
Box 4 provides the ability for the program originator to 
require modification and encryption of the character 
string in the files of the delivered data object 

The "erase table" routine is shown in box 5 and is 
entered from box 4 when all of the table entries have 
been processed. The enabling program then continues 
to box 6, which may optionally recalculate the check 
sum if provided with the software product, the enabling 
program continues to box 7 to erase the warranty screen 
from memory and from the electronically-delivered soft- 
ware product The enabling program then modifies itself 
by erasing the code that allows the nnodification of the 
character strings and the file names. i.e. the unscram- 
bling and renaming, and renames itself "PLACOM" so 
that the Ifcense agreement screens can be recalled if 
desired; it then transfers control to box 11 . 

Box 8 shows the optional warranty routine portion 
of the enabling program which is entered from box 2. 

Box 9 which is entered from box 3. is the character 
string routine that searches for all files in the electroni- 
cally-delivered software product that contain the char- 
acter string placed there by the originator. It modifies 
(and/or encrypts) the string within these files and, when 
all of the accessed character strings have been found 
and modified, this portion retums to the acceptance rou- 
tine in box 3 above. Another purpose of this box 9 is to 
provide a further level of security on use of the product 
If the files which contain the arbitrary character string do 
not contain the modified form which should have result- 
ed from this box operation, then the software originator 
has an easy means for implementing an abort for disa- 
bling use of the code by simply including a test routine 
to test each file when It is accessed for the correct char- 
acter string. Testing for this use of these character 
strings by the software product itself is thus optional. 

Box 10 is invoked from box 4 in the flow chart and 
is the file finding portion of the enabling routine. If the 
software originator has scrambled the original product 
file names, the files will not be usable until the license 
agreement has been accepted by the user and the files 
have been unscrambled. The publisher or originator has 
originally provided a table of cross-references between 
the pseudo file names and the actual file names. The 
routine ends in box 4 which is entered from box 3 as 
noted previously. 

The enabling program ends finally in box 11 whteh 
is entered from box 7 as noted previously. By handing 
control over to the batch file or installation program 
name provided by the software originator, the enabling 
program will then proceed to initialize the actual soft- 
ware product for use. 
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It will be appreciated in the foregoing tliat the re- 
naming or scrambling of the original files is first accom- 
plished by the software originator and that the originator 
also provides, together with the scrambled file, the table 
of corresponding pseudo names or scrambled names 
with their corresponding actual file names. By this 
means the correct file names may be restored by the 
enabling portion of the routine if it, in turn, is enabled by 
the user's acceptance of the license agreement terms 
and conditions. A "self-enabling" facility Is thus built into 
the software product by the originator. This facility is in- 
voked, albeit somewhat unknowingly by the end user. 
In effect, the software product is rendered unusable, 
since internal references within code modules to use 
files or file names will not find the corresponding files or 
file names unless the unscrambling process has been 
carried out previously. The unscrambling process, in 
turn, will not be entered and cannot be invoked unless 
the user has indicated acceptance of the terms and con- 
ditions of the license agreement. The electronic data ob- 
ject as delivered, I.e. the software product as provided 
by the originator, thus contains not only the software 
product program code but the enabling routine together 
with the necessary enabling table and an appropriate 
set of screens and a small annount of control code to 
determine whether the user has indicated acceptance 
or rejection of the license agreement screen informa- 
tion. If acceptance is indicated and the enabling routine 
is al towed to proceed to completion, the routine then 
erases the enabling portions of itself and the enabling 
table. It thus effectively destroys the "keys" or "decryp- 
tion technique" prior to granting access or actual use of 
the software product to the user. Also, tlie enabling pro- 
gram routine as described in the figures includes a step 
that encrypts or othenwise records infomrtation entered 
by the prospective user so that it permanently "marks" 
the user's copy with information that could be later ac- 
cessed by the program originator. This information may 
uniquely identify the user and his/her copy of the soft- 
ware product so that any unauthorized copies that are 
later detected may be traced back to their origin. It will 
thus be seen that a variety of security provisions, some 
of which are optional (i.e., the checksum calculation and 
testing within the software product itself for the modified 
character strings), may be easily included at the selec- 
tion of the program originator while no special provision 
need be made or taken at the user's end to provide ac- 
cess to the delivered software product other than indi- 
cation of acceptance of the terms and conditions which 
will invoke the enabling routine and restore the software 
product to a usable form. 

Extension of these concepts to a variety of other 
fields can be made. For example, the electronically de- 
livered data object need not be a program with license 
agreement screens but could be s\mp\y a certified mes- 
sage or legal document, receipt of which is desired in a 
verified manner. A verification statement and accept- 
ance screen, acceptance of which will be indicated by 



the user, can be utilized to access an acknowledgement 
transmission back to the sender that will occur if and 
only if the recipient agrees to receive the message. By 
a similar obvious extension, the content might not be 
s either a license agreement or a message but could be 
a contract, a bill of lading, or any other document of legal 
significance certified receipt and acceptance of which is 
desired. 

Having thus described our invention with respect to 
10 a preferred embodiment as implemented in simple pro- 
gram routines, it will be obvious to those of skill in the 
art that many modifications and enhancements are pos- 
sible without departing from the basic concepts of the 
self-enabling, self-verifying process of the routine as de- 
15 scribed in the preferred embodiment 



Claims 

20 1 , A system for verifying receipt and acceptance of a 
data object in an information communication sys- 
tem, including a sender and a receiver, said sender 
and receiver being physically separated from one 
another, and including means at said sender for pre- 

ss paring said data object for delivery to said receiver 
and a data delivery means for delivering said data 
object from said sender to said receiver, sakl sys- 
tem comprising: 

30 means at said sender for modifying said data 

object for delivery, said modifying rendering 
said object into an unusable and/or inoperative 
state, and means at said receiver for loading 
said modified data object into a computer for 

3S display and for operations thereon, and being 

characterized in that it comprises: 

means at said sender for inserting an enabling 
means into said data object prior to delivery 
40 thereof. 

means at said receiver for initially accessing 
only said enabling means in said data object 
and for displaying portions of data contained 
45 therein in humanly readable form for soliciting 

a user's response thereto. 

means for entering a user's response, means 
for recording said response; and means for ex- 
50 amining said user's response. 

means conditioned by said examination of said 
user's response for employing said enabling 
means and modifying said data object back to 
55 a usable and/or operative slate. 

2. The system as described in Claim 1 , further com- 
prising: 
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dering said data object usable in case of non 
acceptance by the user. 

8. The method ot Claim 7 wherein: 

5 

said modifying step further comprises inserting 
a verification indicia into said data object, and 

employing said enabling means modifies said 
10 indicia. 

9. The method of Claim 7 or 8, wherein: 

said modifying step further comprises substituting 
new names for existing file component names in 
15 said data object and recording the correspondence 
between said new names and said existing names 
as a portion of said data object at a location acces- 
sible only by said enabling means. 

20 10. The method of Claim 9, wherein: 

said step of employing said enabling means fur- 
ther comprises steps of accessing said record- 
ing of names correspondence and 

2S 

restoring said original names as file component 
names, erasing said record of names corre- 
spondence and said enabling means. 

30 

PatentansprGche 



' means at said sender for inserting a verification 
: indicia into said data object, and 

' means at said receiver for modifying said veri- 
fication indicia in response to said user's re- 
sponse. 

3. The system as described in Claim 1 or 2, wherein 
said receiver includes means responsive to said en- 
abling means for erasing said enabling means re- 
sponsive to said user's response. 

4. The system as described in Claim 1 . 2 or 3, wherein 
said means for modifying comprises means for re- 
placing original component names in said data ob- 
ject with other names not used by said data object, 
and further comprising 

recordkeeping means for recording the correspond- 
ence between replacement component names and 
original component names and for inserting said 
record thereof into said data object. 

5. The system as described in anyone of claims 1 to 
4, wherein said means for modifying said verifica- 
tion indicia modifies said indicia in a manner which 
shows that said enabling means has been em- 
ployed to remodify said data object. 

6. The system as described In Claims 1, 2, 4 or 5, 
wherein said enabling means erases portions of it- 
self from said data object. 

7. A method of verifying receipt and acceptance of a 
data object delivered from a sender to a receiver 
comprising the steps of, at the sender modifying 
said data object into an unusable form; and being 
characterized in that it comprises the steps of: 

at the sender, inserting an enabling means into 
said data object, 

delivering said data object in unusable form and 
including said enabling means to said receiver 
through a single channel between the sender 
and receiver, 

at said receiver tnitialty accessing only said en- 
abling means in said data object and displaying 
portions of data contained therein in humanly 
readable form for solliciting a user's response 
thereto entering a user's resp<xnse, recording 
and examining said user's response, 

. depending upon the user response, employing 
said enabling means to remodify said data ob- 
ject back to a usable form, said remodification 
indicating receipt of and acceptance of said da- 
ta object by said user, or temninate without ren- 



1 . System zum PrOf en von Emptang und Annahme ei- 
nes Datenobjektes in einem InformationsObertra- 

35 gungssystem mit einem Sender und einem Emp- 
fanger, wobei Sender und Empfanger physisch von- 
einander getrennt sind. und mit Mittein an dem Sen- 
der zum Vorbereiten des Datenobjektes zum Zu- 
stellen an den Empfanger und einem Datenzustell- 

40 mittel zum Zustellen des Datenobjektes von dem 
Sender zu dem Empfanger, wobei das System fol- 
gendes umfafBt 

Mittel an dem Sender zum Modifizleren des Da- 
45 tenobjektes zum Zustellen, wobei das Modifi- 

zieren das Objekt in einen nichtverwendbaren 
und/oder funklionsunfahigen Zustand versetzt, 
und IVIittel an dem Empfanger zum l-aden des 
modifizierten Datenobjektes in einen Computer 
so zur Anzeige und fur Operatfonen daran, und 

dadurch gekennzeichnet, da8 es folgendes 
umfaBt 

Mittel an dem Sender zum Einf ugen eines Frei- 
65 gabemittels in das Datenobjekt vor seiner Zu- 

stellung, 

Mittel an dem Empfanger zum anfanglichen Zu- 



7 



MST00006314 



13 



EP0 367 700 B1 



greifen nur auf das Freigabemittel in dem Da- 
tenobjekt und zum Anzeigen von Anteilen von 
darin enthaltenen Dalen in durch den Men- 
schen iesbarer Form, urn eine Antwort eines 
Anwenders darauf anzufordem. 

Mittet zum Eingeben einer Antwort eines An- 
wenders, Mittel zum Aufzeichnen der Antwort 
und Mittel zum Auswerten der Antwort des An- 
wenders, 

Mittel, das abhangig von der Auswertung der 
Antwort des Anwenders dazu dient, das Frei- 
gabemittel einzusetzen und das Datenobjekt in 
einen verwendbaren und/oder funktionsfahi- 
gen Zustand zuruckzuversetzen. 

2. System, wie in Anspruch 1 beschrieben, das wei- 
terhin folgendes umfaBt: 

Mittel an dem Sender zum EinfQgen eines Pruf- 
vermerks in das Datenobjekt, und 

Mittel an dem Emplanger zum Modifizieren des 
Prufvermerks als Antwort aul die Antwort des 
Anwenders. 

3. System, wie In Anspruch 1 oder 2 beschrieben. wo- 
bei der Empfanger Mittel umfaQt, die auf das Frei- 
gabemittel ansprechen, und dazu dienen, das Frei- 
gabemittel zu loschen, in Reaktksn auf die Antwort 
des Anwenders. 

4. System, wie in Ansprucli 1 , 2 oder 3 besclnrieben, 
wobei das Mittel zum Modifizieren Mittel zum Erset- 
zen von Originalkomponentennamen in dem Da- 
tenobjekt durch andere Namen umfaSt, die von 
dem Datenobjekt nicht verwendet werden, und das 
weiterhin folgendes umfaSt: 
Aufzeichnungsmittel zum Aufzeichnen der Korre- 
spondenz zwischen Ersatzkomponentennamen 
und Originalkomponentennamen und zum Elnfu- 
gen der Aufzeichnung davon in das Datenobjekt. 

5. System, wie in irgendeinem der AnsprDche 1 bis 4 
beschneben, wobei das Mittel zum Modifizieren des 
PrOfvermerks den Vermerk auf eine Art nradifiziert, 
die zeigt, da3 das Freigabemittel zum Ruckmodifi- 
zieren des Datenobjektes verwendet wurde. 

6. System, wie in den AnsprOchen 1, 2, 4 oder 5 be- 
schrieben, wobei das Freigabemittel Teile von sich 
selbst von dem Datenobjekt loscht. 

7. Verfahren zum Prufen von Empfang und Annahme 
eines von einem Sender an einen Empfanger zuge- 
stellten Datenobjektes, das die Schritte des Modifi- 
zierens des Datenobjektes bei dem Sender in eine 



nichtverwendbare Form umfaBt; und das dadurch 
gekennzeichnet ist, dafi| es die folgenden Schritte 
umfafit: * 

s bei dem Sender Einfugen eines Freigabemit- 

tels in das Datenobjekt, . 

Zustellen des Datenobjektes in nichtvenwend- 
barer Form und mlt dem Freigabemittel an den 
10 Empfanger durch einen EInzelkanal zwischen 

dem Sender und dem Empfanger, 

bei dem Empfanger anfanglich nur Zugreifen 
auf das Freigabemittel in dem Datenobjekt und 

IS Anzeigen von Teilen der darin enthaltenen Da- 

ten in durch den Menschen Iesbarer Form zum 
Anfordern einer Antwort des Anwenders dazu 
und Eingeben einer Antwort des Anwenders, 
Aufzeichnen und Auswerten der Antwort des 

20 Anwenders, 

abhangig von der Antwort des Anwenders Ver- 
wenden des Freigabemittels. urn das Datenob- 
jekt zuruckzu einer verwendbaren Fomn zu mo- 
25 difizieren, wobei die ROckmodiftkation Emp- 

fang und Annahme des Datenobjektes durch 
den Anwender anzeigt. oder tm Falle einer 
Nichtannahme durch den Anwender Beenden, 
ohne das Datenobjekt venwendbar zu machen. 

30 

8. Vertahren nach Anspruch 7, wobei: 

der Modifizierungsschritt weiterhin das Einfu- 
gen eines PrOfvermerks in das Datenobjekt 
3S umfaBt, und wobei 

das Verwenden des Freigabemittels den Ver- 
merk modifiziert. 

40 9, Verfahren nach Anspruch 7 oder 8, wobei: 

der Modifizierungsschritt weiterhin das Ersetzen 
neuer Namen fur bestehende Datelkomponenten- 
namen in dem Datenobjekt und das Aufzeichnen 
der Korrespondenz zwischen den neuen Namen 

45 und den bestehenden Namen als einen Teil des Da- 
tenobjektes an einer Position, auf die nur durch das 
Freigabemittel zugegriffen werden kann, umfaBt. 

10, Verfahren nach Anspruch 9. wobei: 

so 

der Schritt des Venwendens des Freigabemit- 
tels weiterhin Schritte des Zugreifens auf die 
Aufzeichnung der Namen korrespondenz um- 
faBt, und 

65 

das WIederherstellen der Originalnamen als 
Dateikomponentennamen, Loschen der Auf- 
zeichnung der Namenkorrespondenz und des 
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Freigabemittels. 



Revendicatlons 

1. Syst6me pour verifier la reception at Tacceptation 
d'un objet de donn6es dans un systfemede commu- 
nication d'informations, comprenant un transmet- 
teur et un r^cepteur, lesdits transmetteur et r6cep- 
teur 6tant pliyslquement s§par6s I'un de d'autre. et 
comprenant des moyens, audit transmetteur, pour 
preparer ledit objet de donn§es en vue d'un trans- 
f ert sur ledit r6cepteur et des moyens de distribution 
de donnees pour transferer ledit objet de donnees 
depuis ledit transmetteur jusqu'auditr^cepteur, ledit 
syst^me comprenant: 

des moyens, audit transmetteur, pour modifier 
ledit objet de donn§es en vue d'un transfert, !a- 
dite modification mettant ledit objet dans un 
6tat inutilisable et/ou inactif, et des moyens, 
audit r^cepteur, pour charger ledit objet de don- 
nees modifi6 dans un ordlnateur en vue d'un 
affichage el d'une exploitation de ce demier, 
et etant caract6ris6 en ce qu*il comprend: 
des moyens, audit transmetteur, pour insurer 
un moyen de validation dans ledit objet de don- 
nees avant son transfert, 
des moyens, audit r^cepteur. pour avoir initia- 
lement accfes uniquement audit nnoyen de vali- 
dation dans iedit objet de donnees et pour affi- 
cher des portions de donn6es contenues de- 
dans sous forme humainement lisible pour sol- 
iiclter la r^ponse d*un utilisateur. 
des moyens pour entrer la r6ponse de Putilisa- 
teur, des moyens pour enregistrer ladite repon- 
se. et des moyens pour examiner ladite r6pon- 
se de I'utilisateur, 

des moyens conditionn^s par ledit examen de 
ladite r6ponse de I'utilisateur pour employer le- 
dit moyen de validation et modifier ledit objet 
de donnees de sorts qu'il soit remis dans un 
etat utilisabie et/ou actif. 

2. Syst6me selon la revendication 1, comprenant en 
outre: 

des moyens. audit transmetteur, pour Insurer 
des indices de verification dans ledit objet de 
donnees, et 

des moyens, audit r6cepteur. pour modifier les- 
dits indices de verification en reponse k ladite 
reponse de I'utilisateur. 

3. Systems selon les revendications 1 ou 2, dans te- 
quel ledit recepteur comprend des moyens sensi- 
bles audit moyen de validation pour effacer ledit 
moyens de validation sensible 3 ladite r6ponse de 



I'utilisateur. 

4. Sysieme selon les revendications 1. 2 ou 3. dans 
lequel lesdits moyens pour modifier comprennent 

s des moyens pour remplacer des noms de compo- 
sant d'origine dans ledit objet de donnees par 
d'autres noms non utilises par ledit objet de don- 
nees, et comprenant en outre: 

des moyens de sauvegarde d'enregistrement 

10 pour enregistrer la correspondance entre le rempla- 
cement des noms de composanl et des noms de 
composant d'origine, et pour inserer ledit enregis- 
trement de celle-ci dans ledit objet de donnees. 

ts 5. Systems selon I'une quelconque des revendica- 
tions 1 a 4. dans lequel lesdits moyens pour modi- 
fier lesdits indices de verification modifient lesdits 
indices d'une maniere qui montre que ledit moyen 
de validation a 6te employe pour remodifier ledit ob- 

20 jet de donnees. 

6. Systeme selon les revendicattons 1 , 2, 4 ou 5. dans 
lequel ledit moyen de validation efface des portions 
qui lui sont propres dans ledit objet de donnees. 

25 

7. Methode pour verifier la reception et I'acceptation 
d'un objet de donnees transfere depuis un trans- 
metteur sur un recepteur, comprenant les etapes 
de, audit transmetteur, modifier ledit objet de don- 

30 nees en une fonme inutilisable, 

et etant caract6risee en ce qu'elle comprend 
les etapes de: 

au transmetteur, ins6rer un moyen de valida- 
35 tion dans ledit objet de donnees, 

transferer ledit objet de donnees sous forme 
inutilisable et comprenant ledit moyen de vali- 
dation, sur ledit recepteur par Pintermediaire 
d'un seul canal entre le transmetteur et le re- 
40 cepteur, 

audit recepteur, avoir initialement acces uni- 
quement audit moyen de validatbn dans ledit 
objet de donn6es et afficher des portions de 
donnees contenues dedans sous une forme 
4S humainement Ilslble pour solllciter la reponse 

d'un utilisateur. entrer la reponse de I'utilisa- 
teur, enregistrer et examiner ladite reponse de 
Futilisateur, 

suivant la reponse de Futilisateur, employer le- 
so dit moyen de validation pour remodifier ledit ob- 

jet de donnees de sorts qu'il soit remis en une 
forme utilisabie, ladite remodification indiquant 
la reception d'une acceptation dudit objet de 
donnees par ledit utilisateur. ou la terminaison 
66 sans rendre ledit objet de donnees utilisabie 

dans le cas de non acceptation par I'utilisateur. 

8. Methode selon la revendication 7, dans lequel: 
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ladite §tape de modifier comprend en outre in- 
surer des indices de v6rificatlon dans iedit objet 
de donndes, et 

employer (edit moyen de validation qui modifie 
lesdits indices. 5 

9. M6thode selon les revendications 7 ou 8, dans la- 
queile: 

ladite §tape de modifier comprend en outre 
substrtuer de nouveaux noms aux noms d e compo- io 
sant de fichier existants dans Iedit objet de donn^es 
et enregistrer la correspondance entre lesdits nou- 
veaux noms et lesdits noms existants en tant que 
portion dudit objet de donn^es k un emplacement 
accessible uniquement par Iedit moyen de valida- 
tion. 

10. Mdthode selon la revendication 9, dans laquelle: 

ladite 6tape d' employer Iedit nrrayen de valida- 20 
tion comprend en outre les §tapes tfavoir ac- 
c6s audit enregistrement de la correspondance 
de noms, et 

restaurer lesdits noms d'origine en tant que 
noms de composant de fichier, effager Iedit en- 
registrement de la correspondance de noms et 
Iedit moyen de validation. 



30 



35 



40 



45 
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FIG. 1A 



FIG. 1 



FIG. 

FIG. 
IB 



INTERFACE/FUNCTION 



NOTES 



PROVIDE TEXT FOR THE LICENSE 
AGREEMENT SCREEN(S). ON THE 
LAST SCREEN OF THE LICENSE 
AGREEMENT. THE USER MUST 
INDICATE ACCEPTANCE OR RE- 
JECTION OF THE TERMS AND 
CONDITIONS BEFORE THE 
OBJECT OR SOFTWARE PRODUCT 
WILL BE INSTALLED. 



INSERT A PREDEFINED CHARACTER 
STRING INTO THE PRODUCT'S 
MAJOR MODULE(S)/FILE(S). 
THIS CHARACTER STRING MAY BE 
MODIFIED AND/OR ENCRYPTED 
AFTER THE LICENSE AGREEMENT 
HAS BEEN ACCEPTED BY THE USER. 
MODIFICATION OF THE 
CHARACTER STRING INDICATES 
THAT THE USER HAS ACCEPTED 
THE TERMS AND CONDITIONS 
OF THE LICENSE AGREEMENT. 



THERE MUST BE AT LEAST 
ONE FILE WHICH CONTAINS 
THE CHARACTER STRING. 



CREATE THE COPY OF THE 
PRODUCT OR OBJECT WITH 
THE FILENAMES "SCRAMBLED AND 
GIVEN PSEUDO NAMES. ALSO. 
PROVIDE A TABLE WHICH 
CROSS REFERENCES THE 
PSEUDO (SCRAMBLED) FILE- 
NAMES WITH THE REAL 
FILENAMES. 



THE FILENAMES WILL NOT 
BE RESTORED (i.e.. THE SOFT- 
WARE PRODUCT WILL NOT BE 
USEABLE) UNTIL THE 
LICENSE AGREEMENT HAS 
BEEN ACCEPTED BY THE USER 
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INSERT A TEST ROUTINE INTO THE 
CODE OF EACH OF THE SOFTWARE ' 
PRODUCT MODULES/FILES CON- 
TAINING THE CHARACTER STRING 
TO ALLOW EXECUTION OF THE 

ONLY IF THE STRING HAS BEEN 
MODIFIED (i.e.. THE LICENSE 
AGREEMENT HAS BEEN ACCEPTED 
BY THE USER). 


THE IMPLEMENTATION OF THIS 
OPTIONAL FEATURE BY THE 
SOFTWARE PUBLISHER 
PROVIDES ANOTHER LEVEL 
OF ASSET PROTECTION. 




PROVIDE THE LOCATION IN THE 
SOFTWARE PRODUCT MODULE/FILE 

FOR THE CHECKSUM WHICH WILL 

DC" ocr^Ai r*iii atth tioriM ArrroT— 
DC KtUALLUL Al LU UrUN AuULrl — 

ANCE OF THE LICENSE AGREEMENT 
AND COMPLETION OF THE 
PROCESSING PROGRAM. 


THE IMPLEMENTATION OF THIS 
OPTIONAL FEATURE BY THE 
SOFTWARE PUBLISHER 

OF ASSET PROTECTION. 




PROVIDE A BATCH FILE PROGRAM 
OR INSTALLATION PROGRAM TO 
WHICH CONTROL WILL BE 
TRANSFERRED AT THE COMPLETION 
OF THE ACCEPTANCE VERIFICATION 
ENABLING PROGRAM AFTER THE 
USER HAS INDICATED ACCEPTANCE 
OF THE LICENSE AGREEMENT. 


THIS LINK PROVIDES THE 
TRANSFER BETWEEN THE 
RECEIPT AND ACCEPTANCE 
ENABLING PROCESSING 
PROGRAM AND THE SOFT- 
WARE PRODUCT. 



FIG. IB 
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FIG. 2 



PRESENT THE APPLICABLE TERMS AND CONDITIONS 
TO THE USER BY DISPLAYING THE FOLLOWING: 



RECEIPT AND ACCEPTANCE MENU SCREENS (MAY 
INCLUDE MENU. WARRANTY AND LICENSE 
AGREEMENT SCREENS) 



IF THE USER DOES NOT ACCEPT THE TERMS AND 
CONDITIONS DISPLAYED BY RECEIPT AND 
ACCEPTANCE SCREENS. ABORT AND RETRUN TO 
THE ORIGINAL OBJECT MODULES/ FILES. 
DO NOT ACTIVATE INSTALLATION OF THE 
OBJECT. 



ELSE 

CONTINUE. 



1. 


SEARCH FOR THE CHARACTER STRING. AND 
MODIFY (AND ENCRYPT) THE STRING 
INSERTED BY THE OBJECT ORIGINATOR 
INTO THE OBJECT'S MAJOR FILE(S) 


-2. ENABLE THE OBJECT BY UNSCRAMBLING AND/OR 
DECRYPTING PSEUDO FILENAMES TO THE REAL 
FILENAMES USING THE TABLE PROVIDED BY 
THE OBJECT ORIGINATOR. 


3. 


RECALCULATE THE OBJECT'S CHECK- 
SUM USING THE CHECKSUM LOCATION 
PROVIDED BY THE ORIGINATOR. 
(OPTIONAL FEATURE). 


4. 


MODIFY THE RECEIPT AND ACCEPTANCE PROGRAM 
ITSELF BY DELETING THE CODE THAT PROVIDES 
FOR MODIFICATION OF THE OBJECT'S FILE(S). 


5. 


ACTIVATE THE OBJECT FOR USE OR DISPLAY BY 
TRANSFERRING CONTROL TO THE OBJECT 
MODULE/FILE NAME PROVIDED BY THE OBJECT 
ORIGINATOR. 
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FIG. 3A 

START-OF-PLA-PROCEDURE 



THE END USER INSERTS DISKETTE if^ OF X (OR 
DOWNLOADS THE PRODUCT TO THE HARD DISK). 
SELECTS THE CORRECT DRIVE. AND TYPES 
"GOXXX" (RETURN) AT THE SYSTEM PROMPT. 

"GOXXX" INVOKES CO. COM, THE ENABLING 
PROGRAM 

^ I 

DISPLAY FIRST LICENSE AND/OR WARRANTY 
MENU SCREEN TO THE USER. IT CONTAINS 
INTRODUCTORY INFORMATION AND 
DESCRIBES HOW THE TERMS AND CONDITIONS 
WILL BE PRESENTED TO THE USER. 



CUSTOMIZED TEXT I 



THE USER PRESSES THE ENTER KEY TO 
CONTINUE TO THE SECOND MENU SCREEN. 



2A 



MENU-SELECTION- 
ROUTINE 



FROM THIS MENU SCREEN, THE USER CAN 
SELECT TO (1) READ THE WARRANTY 
INFORMATION PRIOR TO ACCEPTING THE 
T'S AND C'S OR THE LICENSE AGREE- 
MENT. (2) READ THE LICENSE AGREEMENT 
OR (3) ABORT AND RETURN TO THE 
OPERATING SYSTEM. 



IF CHOICE - 1. THEN PERFORM WARRANTY- 
ROUTINE (BOX 8). 

IF CHOICE - 2. THEN CONTINUE TO NEXT BOX. 

IF CHOICE - 3. THEN ABORT AND RETURN TO 
THE OPERATING SYSTEM. 

f - 
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2B 



FIG. 3B 



THE LICENSE AGREEMENT SCREEN(S) ARE 
DISPLAYED TO THE USER. 



CUSTOMIZED TEXT 



FOR MULTIPLE-SCREEN AGREEMENTS. THE 
USER PRESSES THE ENTER KEY TO GO 
FROM SCREEN TO SCREEN UNTIL THE 
LAST SCREEN. THE USER CAN ALSO PAGE 
FORWARD AND BACKWARD WITHIN THE 
AGREEMENT SCREENS. 

ON THE LAST SCREEN OF THE AGREEMENT, 
THE USER IS ASKED TO INDICATE HIS/HER 
ACCEPTANCE OF THE T'S AND C'S OF THE 
LICENSE AGREEMENT, 

IN "N" IS INDICATED, THEN ABORT AND 
RETURN TO THE OPERATING SYSTEM. IF 
"Y" IS INDICATED. THEN CONTINUE TO 
BOX 3 
ELSE 

REQUEST CORRECT RESPONSE AND DO 
NOT PROCEED UNTIL CORRECT RE- 
SPONSE IS ENTERED. 



THE CHARACTER STRING IN THE OBJECT'S 
MAJOR FILE(S) IS MODIFIED IF THE 
LICENSE AGREEMENT HAS BEEN ACCEPTED. 
IF THERE IS A PLA.TAB FILE ON THE DISK/ 
DISKETTE, THEN 

READ PLA. TAB INTO MEMORY 
POSITION TO THE FIRST ROW IN THE 
TABLE CONTINUE TO BOX 4. 



PERFORM CHARACTER-STRING-ROUTINE 
(BOX 9) 

GOTO CHECKSUM-ROUTINE (BOX 6). 




ELSE 



I 
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4A 



PROCESS-TAB- 
ROUTINE: 



I 



IF ALL ROWS OF PLA.TAB HAVE BEEN PRO- 
CESSED. THEN GOTO ERASE-TAB 
ROUTINE (BOX 5). 

ELSE 

PERFORM FIND-FILE-ROUTINE (BOX 10) 
IF COL 2 OF PLA.TAB - THEN 

MODIFY AND ENCRYPT THE SPECIAL 
STRING IN THE FILE ON THE DISK/ 
DISKETTE 
GOTO RENAME-ROUTINE. 
ELSE 

CONTINUE TO NEXT BOX. 



4B 



RENAME-ROUTINE 



I 



FIG.3C 



RENAME THE FILE ON THE DISK/DISKETTE 
FROM THE PSEUDO FILENAME (FROM COL 
XX OF PLA.TAB) TO THE REAL FILENAME 
(FROM COL YY OF PLA.TAB). 

POSITION TO THE NEXT ROW IN PLA.TAB. 

GOTO PROCESS-TAB-ROUTINE (BOX 4). 



ERASE-TAB- 
ROUTINE 



IF GO.COM AND PLA.TAB ARE ON THIS DISK/ 
DISKETTE, THEN 

ERASE PLA.TAB FROM MEMORY AND FROM 

THE DISK/DISKETTE 
GOTO CHECKSUM-ROUTINE (BOX 6). 
ELSE 

REQUEST THE USER TO INSERT DISKETTE 
#1 AND TO PRESS THE ENTER KEY 

REPEAT ERASE-TAB-ROUTINE UNTIL G0.COM 
AND PLA.TAB ARE FOUND. 



CHECKSUM- 
~6l ROUTINE; 



I 



IF CHECKSUM IS NOT USED, THEN CONTINUE 

TO BOX 7. 

ELSE 

RECALCULATE CHECKSUM ON THE 
DISK/DISKETTE. 



I 
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FIG.3D 



ERASE THE WARRANTY SCREEN(S) FROM 

MEMORY AND FROM THE DISK/DISKETTE. 
MODIFY G0.COM BY ERASING THE CODE 

THAT ALLOWS MODIFICATION OF THE 

PROGRAM MODULES/FILES. 
RENAME THE MODIFIED (SMALLER) 

G0.COM TO FLA. COM IN 

MEMORY AND ON THE DISK/ 
- DISKETTE. 

GOTO END-OF-PLA-PROCEDURE (BOX 11). 



8 



WARRANTY- 
ROUTINE: 



i 



THE OBJECT'S WARRANTY SCREEN(S) ARE 
DISPLAYED TO THE USER. 



CUSTOMIZED TEXT 



FOR MULTIPLE-SCREEN WARRANTIES. THE 
USER PRESSES THE ENTER KEY TO GO 
FROM SCREEN TO SCREEN UNTIL THE LAST 
SCREEN. THE USER CAN ALSO PAGE 
FORWARD AND BACKWARD WITHIN THE 
WARRANTY SCREENS. 

AFTER READING THE LAST SCREEN. THE 
USER IS INSTRUCTED TO PRESS THE 
ENTER KEY TO RETURN TO THE WARRANTY 
AND LICENSE MENU SCREEN (#2 OF 2) SO 
THAT HE/SHE CAN THEN SELECT TO READ 
THE LICENSE AGREEMENT. 

RETURN TO MENU-SELECTION-ROUTINE 
(BOX 2). 
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■ CHARACTER- 
STRING-ROUTINE: 



■1 



FIND ALL THE FILES OF THE OBJECT (EXCEPT 
FOR G0.COM) THAT CONTAIN THE SPECIAL 
STRING. MODIFY AND ENCRYPT THE SPECIAL 
STRING IN THE FILE(S). 

IF THE OBJECT IS ON DISKETTE. THEN LOOK 
ONLY ON DISKETTE #1 FOR THE FILES (EXCEPT 
FOR G0.COM) AND MODIFY AND ENCRYPT THE 
SPECIAL STRING IN THE FILE(S) ON 
DISKETTE #1. _ 

WHEN THE STRINGS IN ALL THE REQUIRED 
FILES HAVE BEEN MODIFIED. RETURN TO 
ACCEPT-PLA-ROUTINE (BOX 3). 



10 



FIND-FILE- 
ROUTINE: 



I 



IF THE PSEUDO FILENAME (FROM COL XX OF 
PLA.TAB) IS ON THIS DISK/DISKETTE, THEN 
RETURN TO PROCESS-TAB-ROUTINE (BOX 4). 

ELSE 

REQUEST THE USER TO INSERT DISKETTE #X 
(FROM COL 1 OF PLA.TAB) AND TO PRESS 
THE ENTER KEY 

REPEAT FIND-FILE-ROUTINE UNTIL THE 

FILE IS LOCATED. 



11 



END-OF-PLA- 
PROCEDURE: 



I 



GOTO THE INSTALLATION PROCEDURE FOR THE 
OBJECT BY TRANSFERRING CONTROL TO THE 
BAT FILE OR INSTALL PROGRAM NAME 
PROVIDED BY THE SOFTWARE PUBLISHER. 



STOP 



FIG. 3E 



FIG. 3 
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